Graphical modeling environments come in a number of different varieties. Some graphical modeling environments are time-based and some are state based. In a time based environment it is the passage of time that is the motivating force which drives model execution. Alternatively, in a state based environment it is changes in state which motivate model execution. Each model environment offers numerous benefits to a user, wherein the selection of a time or state driven environment is often based upon the problem to be solved. For example, problems requiring testing and signal processing within a time varying system are best analyzed using a time-driven environment, whereas logic based problems are oftentimes best represented and analyzed using a state driven environment.
An exemplary time-based environment for simulating dynamic systems can be found in Simulink®, which provides tools for modeling and simulating a variety of dynamic systems in one integrated, graphical environment. One of the primary tools used for modeling and simulation of these dynamic systems are blocks. These blocks can be easily manipulated to build block diagrams of a model or system. Each block can implement a function which is commonly used in modeling the system. Example blocks include continuous and discrete dynamics blocks, such as integration and delay blocks or algorithmic blocks, such as sum, product, and lookup table blocks. Furthermore, a user can customize each block, or design new blocks, to more accurately represent the necessary function for use in solving the present problem, simulate the behavior of the system, analyze the performance of the system, and refine the design of the system. Simulink® allows users to design target systems through a user interface that allows drafting of block diagrams of the target systems. All of the blocks in a block library provided by Simulink® and other programs are available to users when the users are building the block diagram of the target systems. Individual users may be able to customize this set of available blocks to: (a) reorganize blocks in some custom format, (b) delete blocks they do not use, and (c) add custom blocks they have designed. The blocks may be dragged through some human-machine interface (such as a mouse or keyboard) from the block library on to the window (i.e., model canvas). Simulink® also allows users to simulate the designed target systems to determine the behavior of the systems.
FIG. 1 shows an example of a Simulink® model. The Simulink® model makes use of blocks and arrows to connect the blocks, when forming the model. Each arrow connecting one block to another represents a signal having a value. Input Signal 100 generates an input signal and sends the signal to a Sum block 102 via link 110. Link 114 communicates the value of the continuous-time state of the Integrator block 104 as a signal from the Integrator block 104 to a Scope block 108 for display, and also sends the signal to a Gain block 106 through link 116. Gain block 106 performs calculation on the input signal from link 116 and outputs the result through link 118 to the Sum block 102. The Sum block 102 adds the signal from link 110 and the signal from link 118 and outputs the result through link 112 to the Integrator block 104. The Integrator block 104 takes the signal from link 112 and performs integration on the value forwarded by the signal to produce an updated output on link 114 at a new point in time. The model continues on indefinitely or until a predetermined condition is achieved, a time period is attained, the user interrupts the execution, or any other termination condition is met.
In contrast to the time based graphical model environment of Simulink®, Stateflow® provides an exemplary state-based flow diagram environment. Stateflow® provides a graphical environment for modeling and designing event-driven systems. Stateflow® describes complex system behavior using finite state machine theory, flow diagram notations, and state-transition diagrams. Stateflow® models state diagrams that graphically represent hierarchical and parallel states and the event-driven transitions between the states of the systems. Stateflow® is integrated with Simulink®, which enables each of the state diagrams to be represented as its own block. Based on the state diagrams created in Stateflow®, Simulink® executes the systems to analyze the behavior of the systems.
An example of a Stateflow® form of state diagram model is shown in FIG. 2A. Each arrow in the Stateflow® models represents a transition, which is a graphical object that, in most cases, links one object to another. One end of a transition is attached to a source object and the other end to a destination object. The source is where the transition begins and the destination is where the transition ends. A transition label describes the circumstances under which the system moves from one state to another. It is always the occurrence of some event that causes a transition to take place. The exemplar Stateflow® diagram as shown in FIG. 2 is embedded in a Simulink® environment. The Simulink® signals are provided to Stateflow®, and Stateflow® uses this information to decide whether there are changes in states.
Within the Stateflow® diagram of FIG. 2A, there are two states: an on state 120 and an off state 122. The default transition 126 determines the initial state is the off state 122. When an on_switch transition 130 is enabled, the enable signal passes to junction 124 and determines whether the temp 134 data is greater or equal to 30, if not, then the enable signal is passed on to signal link 132 and further finish the transition to the on state 120. Now the on state 120 is active and off state 122 inactive. The off state 122 will become active again when the off_switch signal 128 is enabled, at which time the on state 120 will be inactive.
For reasons of simplicity, hereinafter time driven environments will be universally addressed relative to a Simulink® environment example. Furthermore, state driven environments will be universally addressed relative to a Stateflow® environment example. Such a universal application of the Simulink® and Stateflow® environments is not intended to be limiting, and is solely used to aid in describing the present invention.
When working with both Simulink® and Stateflow® environments, it is often difficult to allow for the Simulink® environment to share data with a Stateflow® environment efficiently. This data may include various variable, functionality data or event data. Using current technology, in order for Simulink® data to be accessed from Stateflow® environment, it is necessary to connect the input ports and output ports of the Stateflow® blocks to separate predefined blocks for sharing data between the two environments. This indirection causes memory and runtime inefficiency due to the copying of data between the predefined blocks for receiving and transmitting input and output from the Stateflow® blocks. In addition, this indirection also results in latency where the changes to the data to be shared is not reflected instantaneously.
Therefore, a need exists for a system, method, and apparatus wherein the accessing of data and parameters in a time based graphical programming environment, such as Simulink®, can occur from within a state driven environment such as Stateflow®. In doing so, a user can readily refer to data that exists in the time driven environment directly. This data can then be used in state/transition action statement and other execution specifications within a state driven environment such that the state driven environment automatically resolves this data to the data within the time driven environment. Data accessed and shared in this manner may include various variables that are local or global, functionality data or event data.